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ABSTRACT 


The  translation  of  programming  languages  into  a  form  convenient  for 
execution  is  now  a  well-developed  art.  This  paper  surveys  some  tech¬ 
niques  that  can  be  expected  to  dominate  the  field  in  the  next  few  years. 
The  subjects  discussed  include  language  definition,  recursive  top-down 
source  language  parsers  and  table-driven  bottom-up  parsers,  generation 
of  language-specific  target  code  or  proceeding  further  to  the  code  for 
a  less  hospitable  machine  and,  equivalence  transformations  on  the  vari¬ 
ous  intermediate  forms  of  the  program  to  simplify  the  translator  or 
optimize  the  resulting  code. 
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1 .  Introduction 

The  problem  of  writing  a  programming  language  translator  consists  of 
setting  the  design  objectives,  selecting  the  techniques  to  be  used,  assemb¬ 
ling  the  tools,  carrying  out  the  implementation,  and  finally  "proving"  the 
result.  Properly  done,  the  result  is  an  understandable  program  that  can 
be  easily  changed,  is  relatively  machine  independent,  and  is  free  of 
features  annoying  to  its  eventual  users.  In  practice  this  is  a  big,  but 
achievable,  order. 

In  the  following  pages  the  reader  will  find  illustrations  of  various 
principles,  techniques  and  tools  useful  to  the  translator  writer.  The 
presentation  is  tutorial,  suppressing  some  important  details  in  the  cause 
of  brevity.  Further  information,  including  a  comprehensive  list  of  refer¬ 
ences,  can  be  found  in  Gries  [71]  and  McClure  [72]. 

Some  important  attributes  of  a  translator  are  listed  in  Table  1.1. 

Much  of  the  initial  planning  of  an  implementation  is  concerned  with  choos¬ 
ing  among  them.  The  contents  of  the  table  are  too  much  to  assimilate  all 
at  once,  thus  the  initial  sections  of  this  paper  present  two  translators, 
illustrating  two  recognition  algorithms  and  a  simple  code  generation  scheme. 
The  paper  then  proceeds  to  elaborate  upon  the  theme,  working  up  to  an  organi¬ 
zation  subsuming  most  practical  translators. 

The  mutually  self-describing  grammars  in  Table  1.2  illustrate  a  gram¬ 
matical  notation  combining  the  familiar  context-free  constructs  with 
regular  expression  operators.  Quoting  the  literals  [Rohl  67]  allows  gram¬ 
matical  description  down  to  the  character  level  if  desired.  The  classes 
LETTER  and  CHARACTER  must  be  extended  to  reflect  the  actual  available  char¬ 


acter  sets. 
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Table  1.1 

Translator  Attributes 
The  compiler  is  written  in: 


(a) 

assembly  language,  or 

(b) 

systems  programming  language,  or 

(c) 

general  purpose  language. 

The  recognition  algorithm  is: 

(a)  table-driven,  bottom  up,  or 

(b)  recursive,  top-down. 

There  are  simplifications  and  optimizations  on  the: 


(a) 

token  string,  and/or 

(b) 

computation  tree,  and/or 

(c) 

language-directed  code,  and/or 

(d) 

machine  code. 

The  main  measures  of  efficiency  are: 


(a) 

overall  size  of  the  translator,  and 

(b) 

minimum  memory  in  which  the  translator  can  be  run,  and 

(c) 

translator  speed,  and 

(d) 

ease  of  writing,  and 

(e) 

ease  of  changing  the  translator,  and 

(f) 

speed  of  generated  code,  and 

(g) 

density  of  generated  code. 
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Table  1.2 

Mutually  Self-describing  Grammars 
GOAL  =  TOKEN_LIST  ; 

TOKEN_LIST  =  |  TLI  |  TLN  |  TLL  |  TLS  ; 

TLI  =  (|  TLN  |  TLL  |  TLS)  IDENTIFIER  ; 

TLN  =  (TLI  i  TLL  |  TLS)  NUMBER  ; 

TLL  =  (TLI  |  TLN  |  TLS)  LITERAL  ; 

TLS  =  TOKEN_LIST  SEPARATOR  ; 

IDENTIFIER  =  LETTER  +  ; 


LETTER  = 

'A' 

|  'B' 

|  *  C* 

'  D' 

•E* 

|  »F' 

|  '  G ' 

[  'H' 

1  'I* 

! 

» J ' 

1  'K’  1 

1  '  L ' 

|  'M' 

1  'N'  1 

|  'O' 

|  '  P' 

1  ’Q' 

1  '  R' 

1 

NUMBER  = 

'S’  |  'T' 

DIGIT  +  ; 

'U' 

1  ’V  | 

'W'  j 

|  'X' 

|  1 Y 1 

1  '  Z' 

1  ; 

DIGIT  = 

'O'  | 

'1'  | 

'2'  | 

'3'  | 

'4'  | 

'5'  | 

'6'  | 

1 

•  *N 

Oi 

00 

LITERAL  =  "  "  CHARACTER  +  ' ' ' '  ; 

CHARACTER  =  LETTER  |  DIGIT  |  SEPARATOR  |  *  "  *  "  "  ; 

SEPARATOR  =  '  =  '  |  ';'  |  »|»  |  |  '+'  |  |  '('  |  ')'  |  •  ' 


GOAL  =  RULE  +  ; 

RULE  =  IDENTIFIER  '  =  '  FORM  * ; *  ; 

FORM  =  DEFINITION  (  '  |  '  DEFINITION  )  *  ; 
DEFINITION  =  CLASS  (  '-'  CLASS  )  *  ; 

CLASS  =  (PRIMARY  (|  '*'  |  '  +  '  |  NUMBER  ))*  ; 
PRIMARY  =  IDENTIFIER  |  LITERAL  |  '(•  FORM  ')'  ; 
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The  first  grammar  (a  lexical  grammar)  describes  both  grammars  as 
strings  of  symbols  where  the  actual  detail  of  the  internal  structure  of 
the  symbols  and  separators  is  given.  Because  two  identifiers  together 
look  like  one,  a  TLI  (token  list  followed  by  an  identifier)  may  never 
be  followed  by  another  identifier.  Similar  comments  apply  to  quoted 
items  and  numeric  items.  The  second  grammar  (a  grammar- grammar)  des¬ 
cribes  both  grammars  as  sequences  of  rules  where  the  symbol  ( ' | ' )  sepa¬ 
rates  alternatives.  Within  a  definition  we  may  take  the  difference 
between  two  phrase  classes  ('-')  or  repeat  them  '+'.  INTEGER). 

We  will  use  this  notation  extensively  in  the  following  pages. 

A  translator  accepts  a  source  text  convenient  for  programming  and 
transforms  it  into  a  target  code  suitable  for  executing.  To  understand 
the  translation  process,  one  must  first  have  a  good  grasp  of  the  meaning, 
of  a  source  text  and  a  target  code. 

For  example,  the  source  text 
A  =  -A+5*B/(B-1) ; 

might  be  translated  into  the  following  zero-address  target  code: 


* 
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LIT  A; 

LIT  A; 

LOAD; 

NEG; 

LIT  5; 

LIT  B; 

LOAD; 

MUL; 

LIT  B; 

LOAD; 

LIT  1; 

NEG; 

ADD; 

DIV; 

ADD; 

STORE; 

Table  1.5 

Table  1.3  is  a  grammar  for  assignment  statements.  Given  that  the 
variables  must  contain  integers,  such  statements  have  well  defined  mean¬ 
ings.  We  presume  that  the  reader  is  familiar  enough  with  Algol  or  PLA 
to  be  able  to  follow  such  examples  and  also  simple  programs. 

Table  1.4  is  a  grammar  for  the  zero-address  target  code  in  the  exam¬ 
ple  above.  Even  though  the  meaning  of  the  target  code  is  probably 
obvious  to  our  readers,  we  will  use  a  few  words  to  describe  it. 

There  is  an  evaluation  stack  into  which  values  can  be  pushed. 
Furthermore,  the  top  values  (hence  the  last  ones  pushed  into  the  stack) 
are  available  to  be  used  in  computations.  The  LIT  instruction  pushes 
one  value  onto  the  stack.  The  value  is  either  an  address  (e.g.,  the 


-6- 


address  of  the  variable  A  in  LIT  A)  or  a  constant  (e.g.  the  value  5  in 
LIT  5) .  The  LOAD  instruction  assumes  the  top  value  on  the  stack  is  an 
address.  The  address  is  removed  from  the  stack  and  the  value  found  in 
the  indicated  cell  in  memory  is  pushed  onto  the  stack  in  its  place.  The 
STORE  instruction  must  be  supplied  with  two  items  at  the  stack  top.  One 
is  the  address  of  a  cell  in  memory.  The  other  is  a  value  to  be  stored 
into  the  indicated  cell  (the  address  is  below  the  value  in  the  stack) . 
After  the  instruction  has  completed  its  action,  both  address  and  value 
are  removed  from  the  stack.  The  remainder  of  the  instructions  are  arith¬ 
metic  operations.  NEG  changes  the  sign  of  the  top  value  on  the  stack  and 
leaves  it  where  it  found  it.  ADD,  MUL  and  DIV  operate  on  the  two  top 
elements  on  the  stack,  removing  them  and  then  placing  the  result  back  on 
the  stack. 


-7- 


Table  1.3 

A  Source  Language  Grammar 

ASSIGNMENT  =  VARIABLE  '  =  '  EXPRESSION  ; 

EXPRESSION  =  (l'-’)TERM  (( '  + ' | ' - ' )TERM) *  ; 

TERM  =  PRIMARY  (('*'|'/')  PRIMARY)*  ; 

PRIMARY  =  CONSTANT  |  VARIABLE  |  '('  EXPRESSION  ')'  ; 

VARIABLE  =  IDENTIFIER  ; 

Note:  CONSTANT  and  IDENTIFIER  are  processed  in  the  scanner,  making  their 

definition  here  irrelevant. 


Table  1.4 

A  Target  Language  Grammar 
ASSIGNMENT  =  VARIABLE  EXPRESSION  'STORE*  ; 

EXPRESSION  =  'LIT'  CONSTANT  |  VARIABLE  'LOAD' 

|  EXPRESSION  'NEG' 

|  EXPRESSION  EXPRESSION  ( ' ADD' | 'MUL' | ' DIV' )  ; 

VARIABLE  =  'LIT'  IDENTIFIER  ; 

Note:  Both  IDENTIFIER  and  CONSTANT  are  represented  by  bit  patterns  in  the 
machine  code.  The  first  is  to  be  interpreted  as  the  address  of  the  variable 
and  the  second  as  the  value  of  the  corresponding  constant  in  the  source 
language . 


-8- 


For  both  the  top-down  and  bottom-up  translators,  the  example  above  will 
be  worked  in  detail. 

The  step-by-step  execution  of  the  example  zero-address  target  code  is 
depicted  in  Figure  1.1. 
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Figure  1.1 


Successive  stack  configurations  during 
Note:  M(A)  =  7,  M(B)  =  6. 


LIT  A  LIT  A  LOAD 


6 

B 

5 

30 

30 

-7 

-7 

-7 

A 

A 

A  j 

) 

LOAD 

MUL 

LIT  B 

6 

-7 

A 

-1 

A 

DIV 

ADD 

STORE 

execution  of  the  code  in  Table  1.5. 


-7 

A 

5 

-7 

A 

B 

5 

-7 

A 

LIT  5 

LIT  B 

1 

-1 

6 

6 

6 

5 

30 

30 

30 

30 

-7 

-7 

-7 

-7 

A 

A 

A 

A 

LIT  1 

NEG 
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2 .  A  Top-down  Translator 

The  recursive  recognition  technique  is  one  of  those  ideas  that  is  so 
simple  that  nobody  ever  bothers  to  write  much  about  it.  It  is,  however, 
in  many  cases  the  easiest  method  of  writing  good  translators.  The  pre¬ 
requisites  are  a  syntactic  definition  of  the  source  language  (which  then 
becomes  the  translator  writer's  flow  chart)  and  a  recursive  language  in 
which  to  write  (e.g.,  assembler,  PL/360,  Algol  and  PL/1  but  not  Fortran 
or  XPL) .  A  partial  narration  of  the  program  carrying  out  the  translation 
depicted  in  Table  1.5  follows.  Refer  to  Figure  2.1  and  Table  2.1. 

Initially  (line  85),  token  is  undefined  and  is  then  set  to  'A'  by  the 
first  call  of  scan  (line  87) .  Then  assignment  is  called,  immediately  calls 
variable  (line  16)  which  checks  to  make  sure  an  identifier  has  been  found 
(line  77)  (notice  that  we  hide  this  decision  inside  the  undefined  function 
identifier  to  avoid  unnecessary  detail).  Since  'A'  is  an  identifier,  the 
test  is  passed  and  the  pair  'LIT'  'A'  is  emitted,  and  'A'  is  discarded  by 
a  second  call  of  scan  (line  81),  leaving  '='  in  token.  Returning  from 
variable  to  assignment  (line  16)  the  '='  is  noted,  then  discarded  and 
replaced  by  the  next  token  The  right-hand  side  of  the  assignment  is 

then  processed  with  a  call  to  expression.  Table  2.1  gives  a  complete  summ¬ 
ary  of  the  remaining  actions;  the  reader  is  encouraged  to  complete  the 


simulation  of  the  recursive  translator. 
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Figure  2.1 

A  Simple  Recursive  Translator  for  Assignments  into  Zero-address  Code 

translate : 
procedure; 

/*  scan  and  emit  are  left  undefined  in  this 
example  to  avoid  irrelevant  detail  */ 

scan : 

procedure  returns  (character  varying) ; 

/*  produces  the  next  token  each  time  called  */ 
end  scan; 

declare  token  character  varying; 


emit : 

procedure  (op  character  varying) ; 

/*  assembles  zero-address  code  */ 
end  emit; 
assignment : 
procedure; 

call  variable; 

if  token  =  '  =  '  then  token  =  scan; 
else  call  error; 
call  expression; 
call  emit  ('STORE'); 


end  assignment; 
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expression  : 
procedure ; 

declare  t  character  (1); 

/*  check  for  unary  minus  */ 

if  token  =  ' - '  then 

do; 

token  =  scan; 
call  term; 
call  emit  ( 'NEG' )  ; 
end; 

else  call  term; 

do  while  token  =  '-'  |  token  =  '  +  '; 
t  =  token;  token  =  scan; 
call  term; 

if  t  =  '-'  then  call  emit  ('NEG'); 
call  emit  ('ADD') ; 
end; 

end  expression; 
term: 

procedure ; 

declare  t  character  (1); 
call  primary; 

do  while  token  =  ' *'  |  token  =  '/'; 
t  =  token;  token  =  scan; 
call  primary; 

if  t  =  ' *~'  then  call  emit  ('MUL'); 
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else  call  emit  ( * DI V ' ) ; 
end; 

end  term; 
primary : 

procedure ; 

/*  check  for  a  constant  */ 
if  constant  (token)  then 
do; 

call  emit  ( ' LIT' ) ; 
call  emit  (token) ; 
token  =  scan; 
end; 

/*  check  for  parenthesized  expression  */ 

else  if  token  =  '('  then 

do; 

token  =  scan; 
call  expression; 

if  token  =  ')'  then  token  =  scan; 
else  call  error; 
end; 

/*  assume  that  it  is  a  variable  */ 

else 

do; 

call  variable; 
call  emit  ('LOAD'); 
end; 


end  primary; 
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variable  : 

procedure ; 

if  identifier  (token)  then 
do; 

call  emit  ( ' LIT’ ) ; 
call  emit  (token); 
token  =  scan; 
end; 

else  call  error; 
end  variable; 

/*  main  body  of  translator  */ 
/*  get  initial  token  value  */ 
token  =  scan; 
call  assignment; 


end  translate; 
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Table  2.1 


Summary  of  the  Actions  of  the  Top-down  Translator 


Source  text 
remaining 


Target  code 
produced 


Active  line 

Value 

in  the 

of 

top-down 

recognizer 

token 

start 

undefined 

87 

A 

88 

16 

77 

80 

A 

81 

17 

19 

26 

28 

A 

43 

54 

61 

69 

71 

77 

80 

A 

81 

+ 

72 

+ 

44 

30 

+ 

33 

34 

5 

35 

43 

54 

57 

5 

58 

* 

44 

45 

A=-A+5*B/ (B-l) 

=-A+5*B/(B-l) 

=-A+5*B/ (B-l)  LIT  A 

-A+5*B/ (B-l) 

A+5*B/(B-1) 

+5*B/ (B-l) 


+  5*B/ (B-l) 

LIT  A 

5*B/ (B-l) 

LOAD 

5*B/ (B-l) 

5*B/ (B-l) 

NEG 

*B/ (B-l) 

*B/ (B-l) 

LIT  5 

B/ (B-l) 
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46 
54 
61 

71 
77 
80 

81 

72 

47 

44 

45 

46 
54 
61 

63 

64 
26 

32 

43 
54 
61 

71 
77 
80 

81 

72 

44 

33 

34 

35 

43 
54 

57 

58 

44 

36 

37 

33 

65 

47 

48 


B  /  (B  - 1 ) 


B 

/ (B-l) 

LIT 

/ 

(B-l) 

/ 

(B-l) 

LOAD 

/ 

(B-l) 

MUL 

( 

B-l) 

B  -1) 


B  -1)  LIT  B 

1) 

1)  LOAD 

1  ) 

1  ) 

) 

) 

) 

DIV 


LIT  1 

NEG 

ADD 
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44 

36 

37 

33 

20 

89 


ADD 

STORE 
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The  success  of  the  recursive  technique  is  due  to  several  circumstances. 
First,  the  mapping  from  a  syntactic  description  to  a  recognizer  (Table  1.3 
to  Figure  2.1)  is  so  simple  that  an  experienced  programmer  can  do  it  as  fast 
as  he  can  write.*  Second,  the  programmer  can  insert  his  generator  code  between 
any  two  statements  of  the  recognizer.  This  implies  that  whenever  any  struc¬ 
tural  entity  of  the  source  language  has  been  recognized,  the  programmer  has 
a  convenient  opportunity  to  attach  an  interpretation  to  it.  Third,  because 
the  local  variables  of  recursive  procedures  are  in  fact  in  a  run-time  stack, 
the  programmer  may  associate  temporary  information  with  any  source  language 
construct  (see  the  variables  t  in  procedures  expression  and  term,  lines  24 
to  42)  without  laboriously  building  stack  data  structures  in  his  translator. 
One  must  reflect  on  the  pervasive  nature  of  stacks  in  translators  to  appre¬ 
ciate  the  value  of  getting  them  for  "free".  Perhaps  the  most  important 
advantage  of  the  recursive  technique,  aside  from  its  simplicity,  is  the  fact 
that  it  can  handle  complex  languages  without  catastrophic  costs  in  size  or 
speed. 

The  recursive  technique  is  of  no  particular  help  beyond  the  production 
of  a  language-directed  code  (e.g.,  zero-address  code  for  assignments). 

Since  the  great  bulk  of  the  work  in  writing  a  compiler  for  the  average  mod¬ 
em  computer  comes  in  turning  the  language-directed  code  into  good  machine 
language,  the  helpful  properties  detailed  above  can  look  rather  irrelevant 
to  a  hard-pressed  implementor. 

In  addition  to  the  need  for  a  recursive  language  in  which  to  write,  the 
recursive  technique  has  one  serious  disadvantage.  The  generator  and  par¬ 
ser  are  thoroughly  mixed  together,  preventing  the  programmer  from  treating 
them  separately  for  purposes  of  documentation,  maintenance,  memory  manage¬ 
ment,  testing,  and  so  forth.  In  particular,  it  is  not  unusual  to  find  target 
code  dependencies  in  the  source  language  recognizer,  preventing  the  recog¬ 
nizer  from  being  machine  independent. 

*  Frank  DeRemer  points  out  that  the  simplicity  rapidly  disappears  if  good 
diagnostics  and  error  recovery  are  required. 
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3.  A  Bottom- up  Translator 

The  actions  of  a  bottom-up  translator  separate  into  the  actions  that 
produce  the  canonical  parse  and  those  that  the  synthesizer  takes  when  act¬ 
ing  on  the  canonical  parse.  Because  the  canonical  parse  is  most  easily 
understood  in  relation  to  a  context-free  grammar.  Table  3.1  is  substitu¬ 
ted  for  Table  1.3  without  changing  the  source  language.  The  procedure 
synthesize  (Figure  3.1,  line  47),  called  with  the  sequence  of  rule  numbers 
in  the  left-hand  column  of  Table  3.2,  will  produce  the  sequential  language- 
directed  code  in  the  right-hand  column  of  Table  3.2. 

The  remainder  of  Figure  3.1  is  a  source  language  independent  parsing 
algorithm  driven  by  the  mixed  LR(O) ,  LR(1)  recognition  tables  in 
Table  3.3.  The  tables  are  interrogated  in  parse  (line  100)  where  state_ 
type  is  set  to  the  values  0  through  3  corresponding  to  tabulated  entries 
blank,  S,  SR  and  R  which  in  turn  stand  for  syntax  error,  stack  the  present 
state  and  apply  rule  N,  and  apply  rule  N. 

Translation  starts  on  line  126  where  the  syntax  tables  are  initial¬ 
ized,  the  initial  state  is  stacked  and  the  initial  value  of  token  is 
scanned.  The  recognizer  is  called  and  the  loop  on  line  98  is  entered.  The 
variables  state-type  and  N  are  assigned  the  values  2  (i.e.,  entry  SR)  and 
12  (the  intersection  of  row  IDENTIFIER  and  column  1  of  Table  3.3).  The 
case  statement  selects  the  stack -and- reduce  case  (line  109)  where  a  dummy- 
state  (0)  and  the  identifier  'A'  are  stacked.  Synthesize  is  called  with 
parameter  12  (line  112)  (line  54)  selects  the  last  case  (line  88)  causing 
'LIT*  'A'  to  be  emitted.  Returning  to  the  parser  (line  113)  one  item  is 
popped  off  each  stack,  leaving  the  initial  state  (1)  exposed.  Token  is 
set  to  VARIABLE.  Execution  continues  on  line  100  where  state_type  and  N 
assume  new  values  1  and  15,  respectively. 
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Table  3.1 

Context  - 

-free  Grammar  for  the  Assignment  Source  Language 

rule  number 

rule 

1 

ASSIGNMENT  =  VARIABLE  '='  EXPRESSION  'Jj  ; 

2 

EXPRESSION  =  TERM 

3 

|  TERM 

4 

|  EXPRESSION  '+'  TERM 

5 

|  EXPRESSION  ' - '  TERM  ; 

6 

TERM  =  PRIMARY 

7 

|  TERM  PRIMARY 

8 

|  TERM  '/'  PRIMARY  ; 

9 

PRIMARY  =  CONSTANT 

10 

|  VARIABLE 

11 

|  ' ('  EXPRESSION  ')'  ; 

12 

VARIABLE  =  IDENTIFIER  ; 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 

23 

24 

25 
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Figure  3.1 

A  Bottom-up  Translator 


translate : 
procedure ; 

/*  auxiliary  procedures  */ 
/*  token  handlers  */ 


scan : 

procedure  returns  (  character  varying); 

/*  produces  next  token  each  time  it  is  called  */ 
end  scan; 

/*  global  residence  of  the  current  token  */ 
declare  token  character  varying; 
unscan : 

procedure (s  character  varying); 

/*  reverses  the  effect  of  scan  */ 
end  unscan; 

/*  stack  handlers  */ 

/*  global  residence  of  last  token  stacked  or  uncovered  */ 
declare  top_of_token_stack  character  varying; 

/*  global  residence  of  last  state  stacked  or  uncovered  */ 
declare  top_of_state_stack  fixed; 
push : 

procedure(s  fixed,  t  character  varying); 

/*  push  s  onto  the  state  stack  and  t  onto  the 
token  stack,  s  and  t  are  resident  in 
top_of_state_stack  and  top_of_token_stack  */ 
end  push; 
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pop  : 

procedure (n  fixed) ; 

/*  discards  n  items  from  each  stack,  placing 
newly  uncovered  values  in  top_variables  */ 
end  pop; 

/*  LR  table  access  */ 
table : 

procedure (s  fixed,  t  character  varying) 
returns (a  fixed,  n  fixed); 

/*  two-valued  procedure  returning  values  found; 
in  Table  3.3  */ 
end  table; 
left_part : 

procedure (p  fixed)  returns (t  character  varying); 

/*  t  is  the  left  part  of  rule  p  in  Table  3.1  */ 
end  left_part; 
length : 

procedure (p  fixed)  returns (k  fixed); 

/*  k  is  the  number  of  items  on  the  right  side 
of  rule  p  in  Table  3.1  */ 
end  length; 
synthesize : 

procedure (p  fixed); 
emit : 

procedure (op  character  varying); 

/*  assembles  one  item  of  zero-address  code  */ 


end  emit; 
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/*  switch  on  rule  number  */ 
do  case  p; 

/*  no  rule  number  zero  */ 

/*  ASSIGNMENT  =  VARIABLE  '  =  '  EXPRESSION  */ 
do; 

call  emi t(' STORE' ) ; 
return  from  translate; 
end; 

/*  EXPRESSION  =  TERM  */ 

/*  EXPRESSION  =  TERM  */ 
call  emit ( 'NEG ' ) ; 

/*  EXPRESSION  =  EXPRESSION  '+'  TERM  */ 
call  emit ('ADD') ; 

/*  EXPRESSION  =  EXPRESSION  TERM  */ 
do; 

call  emit('NEG') ; 
call  emit ( ' ADD' ) ; 
end; 

/*  TERM  =  PRIMARY  */ 

/*  TERM  =  TERM  '+'  PRIMARY  */ 
call  emit ( 'MUL' ) ; 

/*  TERM  =  TERM  '/'  PRIMARY  */ 
call  emit ( ' DIV' ) ; 

/*  PRIMARY  =  CONSTANT  */ 
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do; 

call  emit ( ' LIT' ) ; 
call  emit(top_of  token_st ack) ; 
end; 

/*  PRIMARY  =  VARIABLE  */ 
call  emit (' LOAD' ) ; 

/*  PRIMARY  =  '('  EXPRESSION  ')'  */ 

/*  VARIABLE  =  IDENTIFIER  */ 
do; 

call  emit( ' LIT' ) ; 
call  emit (top_of_token_stack) ; 
end; 
end; 

end  synthesize; 
parse; 

procedure ; 

declare  (state_type,  N)  fixed; 
do  forever; 

/*  get  the  values  from  Table  3.3  */ 
state_type,  N  =  table(top  of  state_stack,  token); 
do  case  state  type; 

/*  syntax  error  */ 
call  error; 

/*  stack  */ 
do; 

call  push(n,  token); 
token  =  scan; 
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end; 

/*  stack  and  reduce,  LR(0)  case  */ 
do; 

call  push(0,  token); 
call  synthesize (N) ; 
call  pop ( length (N) ) ; 
token  =  left_part (N) ; 
end; 

/*  reduce,  LR(1)  case  */ 
do; 

call  synthesize (N) ; 
call  pop ( length (N) ) ; 
call  unscan (token) ; 
token  =  left_part (N) ; 
end; 
end; 
end; 

end  parse; 

/*  main  body  of  translate  */ 

/*  initialize  read-only  syntax  tables  */ 
call  initialize_tables ; 

/*  initialize  the  stacks  */ 
call  push(l ,  ' ' ) ; 

/*  read  the  first  token  of  the  source  text  */ 
token  =  scan; 
call  parse; 


end  translate; 
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Table  3.2 


Association  of  the  Canonical  Parse  and  Code  Generation 


applied 


emitted  code 


partially  parsed  text 


A=-A+5*B (B-l) | 

VARIABLE^ IDENTIFIER  LIT  A 

VARIABLE=-A+5*B/ (B-l) | 

VARIABLE= IDENTIFIER  LIT  A 

VARIABLE=-VARIABLE+5*B/B(B-1) 

PRIMARY= VARIABLE  LOAD 

VARIABLE=-PRIMARY+5*B/ (B-l) | 

TERM= PRIMARY 


VARIABLE=-TERM+5*B/ (B-l) | 

EXPRESSION=-TERM  NEG 

VARIABLE=EXPRESSI0N+5*B/ (B-l)  | 

PRIMARY= CONSTANT  LIT  5 

VARIABLE=EXPRESSI0N+PRIMARY*B/(B-1) | 

TERM= PRIMARY 


VARIABLE=EXPRESSION+TERM*B (B-l) | 

VARIABLE= IDENTIFIER  LIT  B 

VARIABLE=EXPRESSI0N+TERM*VARIABLE/(B-1) | 
PRIMARY= VARIABLE  LOAD 

VARIABLE=EXPRESSION+TERM*PRIMARY/ (B-l) | 
TERM=  TE  RM*  P  RIMARY  MUL 

VARIABLE=EXPRESSI0N+TERM/(B-1) | 
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VARIABLE= IDENTIFIER 

VARIABLE=EXPRESSION+TERM/ (VARIABLE -1) 
PRIMARY= VARIABLE 

VARIABLE=EXPRESSION+TERM/ (PRIMARY- 1) | 

TERM=PRIMARY 

VARIABLE=EXPRESSION+TERM/ (TERM-1) | 
EXPRESS I0N=TERM 

VARIABLE=EXPRESSION+TERM/ (EXPRESSION- 
PRIMARY=CONSTANT 

VARIABLE=EXPRESSION+TERM/ (EXPRESS ION - 

TERM=PRIMARY 

VARIABLE=EXPRESSION+TERM/ (EXPRESSION- 
EXPRESSION=EXPRESSION-TERM 

VARIABLE=EXPRESSION+TERM/ (EXPRESSION) 
P RIMARY = (EXPRESSION) 

VARIABLE=EXPRESSION+TERM/PRIMARY | 
TERM= TERM/ PRIMARY 

VARIABLE=EXPRESSION+TERM| 

EXPRESS I ON=EXPRESSION+TERM 

VARIABLE=EXPRESSION | 
ASSIGNMENT=VARIABLE=EXPRESSION| 


LIT  B 

LOAD 


i)J_ 

LIT  1 
PRIMARY) 

TERM)J_ 
NEG  ADD 


DIV 

ADD 

STORE 


ASSIGNMENT 
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Table  3.3 

Syntax  Tables  for  Mixed  LR(O)  and  LR(1)  Parsing  Algorithm 


state 


1  2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

i 

r 

1  ’ 

SR 

R 

R 

R 

R 

| 

I  } 

1 

2 

3 

4 

5 

1 

f 

i 

( 

S 

S 

S 

S 

S 

S 

S 

1 

(  f 

3 

3 

3 

3 

3 

3 

3 

i 

i 

SR 

R 

R 

R 

R 

1 

j 

)  1 

11 

2 

3 

4 

5 

j 

i 

i 

S  ! 

2 ! 

j 

S 

S 

R 

R 

R 

R 

1 

l 

+  i 

4 

4 

2 

3 

4 

5 

i 

S 

S 

S 

S 

R 

R 

R 

R 

t 

-  ; 

5 

5 

6 

6 

2 

3 

4 

5 

f 

\ 

V 

S 

S 

S 

S 

*  J 

7 

7 

7 

7 

> 

1 

i. 

S 

S 

S 

S 

/  ! 

8 

8 

8 

8 

; 

ASSIGNMENT  j 


EXPRESSION 

. 

i 

[ 

■ 

S 

9 

S 

10 

1 

S 

S 

S 

S 

S 

TERM 

I 

11 

11 

13 

12 

14 

l 

j 

SR 

SR 

SR 

SR 

SR 

SR 

SR 

PRIMARY 

| _ 

6 

6 

6 

6 

6 

7 

8 

i 

[ 

1 

SR 

SR 

SR 

SR 

SR 

SR 

SR 

CONSTANT 

1 

9 

9 

9 

9 

9 

9 

9 

Hs 

SR 

SR 

SR 

SR 

SR 

SR 

SR 

VARIABLE  ! 

15 

10 

10 

10 

10 

10 

10 

10 

1 

!  SR 

SR 

SR 

SR 

SR 

SR 

SR 

SR 

IDENTIFIER 

12 

12 

12 

12 

12 

12 

12 

12 

Table  3.3  is  equivalent  to  LALR(l)  parsing  tables  [DeRemer  69] 


-29- 


There  are  programs  that  produce  syntax  tables  similar  to  Table  3.3 
from  input  similar  to  Tables  3.1  or  1.3.  How  it  is  done  is  an  interest¬ 
ing  subject  but  of  no  direct  concern  to  the  translator  implementor  who 
need  only  write  the  procedure  synthesize.  There  are,  however,  fewer  oppor¬ 
tunities  to  attach  interpretations  to  the  parsing  actions  since  synthesize 
is  called  only  from  SR  and  R  decision  and  not  S  decisions.  And,  except 
for  the  state  and  token  stack,  the  programmer  must  build  his  own  data 
structures . 


-30- 


4 .  An  Elaborate  Compiler 

A  compiler  accepts  source  text  records  and  produces  records  full  of 
machine  code  ready  for  execution.  During  the  process  the  program  may 
assume  several  intermediate  forms,  including: 

records 

string  of  characters 
string  of  tokens 
phrase-structure  tree 
computation  tree 

language-specific  sequential  code 
machine-specific  sequential  code 
records 

The  design  of  a  translator  depends  heavily  on  which  of  the  above  forms  are 
to  be  used.  Generally  speaking,  the  more  complex  the  source  text,  the 
higher  the  payoff  in  making  the  compiler  more  elaborate.  Once  the 
sequence  of  intermediate  forms  has  been  chosen,  getting  from  one  form  to 
another  represents  the  major  implementation  problem.  Performing  transform¬ 
ations  on  the  intermediate  forms  to  simplify  the  remaining  tasks  or  improve 
the  quality  of  the  resulting  machine  code  may  be  a  subsidiary  task.  The 
overall  data  flow  for  an  elaborate  compiler  is  given  in  Figure  4.1.  The 
remainder  of  this  paper  is  devoted  to  explaining  the  meaning  of  the  various 
algorithms  and  data  structures  depicted  in  the  figure. 
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Figure  4.1 

An  Elaborate  Compiler 


source  text 


records 


character  string 


translator  control  information 
program  listing 

lexical  error  messages 
string  table 


token  string 


simplified 
token  string 

phrase - 

structure  tree 


simplified 
computation  tree 

language- specific 
sequential  code 


optimized 
language-specific 
sequential  code 

machine  specific 
sequential  code 

optimized 
machine  code 


records 


executable  program 


assembly  listing 


-32- 


5.  Transformation  on  the  Token  String 

The  problem  of  translating  a  very  complex  language  (e.g.,  the  IBM  PL/1) 
can  be  simplified  by  passing  repeatedly  over  the  token  string,  each  time 
producing  an  equivalent  token  string  with  fewer  primitive  concepts.  The  final 
set  of  primitives  is  usually  taken  to  include  GO  TO,  IF,  assignments  and  other 
things  that  map  directly  onto  a  conventional  instruction  set. 

Table  5.1  displays  three  successive  equivalence  transformations  on  a  PL/1 
program.  Initially  there  is  an  array  assignment  which  implies  a  loop 
(stage  2).  The  translator  has  had  to  create  some  new  identifiers  which  are 
started  with  '$'  to  avoid  confusion.  The  control  expressions  of  the  do-loop 
are  evaluated  only  once  implying  that  the  head  of  the  loop  contains  only  sim¬ 
ple  variables  (stage  3) .  The  loop  itself  can  then  be  factored  into  IF  and  GO  TO 
constructs  (stage  4) . 

The  advantages  are  the  already  mentioned  reduction  in  overall  translator 
complexity  and  also  the  fragmentation  of  the  translator  to  aid  in  making  each 
piece  small  enough  to  permit  running  in  a  small  memory.  It  has  some  utility 
in  documenting  the  meaning  of  language  constructs  where  the  transformations 
are  simple  enough  to  be  easily  understood. 

The  technique  has  some  disadvantages.  It  can  be  slow  since  repeated 
passes  over  the  token  string  are  required.  Clever  methods  of  speeding  things 
up  may  cancel  the  gain  in  simplicity  that  led  to  its  use  in  the  first  place. 
There  is  also  a  lack  of  theory  governing  the  transformations,  leaving  a  poten¬ 
tially  confusing  series  of  ad-hoc  algorithms.  Finally,  the  transformations 
may  obscure  relations  that  would  have  been  useful  to  the  generators.  For 
instance,  the  fact  that  the  example  in  Table  5.1  can  be  accomplished  with  a 

single  memory  to  memory  block  transfer  instruction  will  never  be  recovered 
from  the  "simplified"  form  at  stage  4. 
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Table  5.1 

Successive  Transformations  of  a  PL/I  Program  Fragment 

DECLARE  (A,B)  (20)  FIXED; 

A  =  B; 


DECLARE  (A,B)  (20)  FIXED; 

DECLARE  $11  FIXED; 

DO  $11  =  LBOUND(A)  TO  HBOUND(A) ; 

A($I 1)  =  B ( $ I 1 ) ; 

END; 


DECLARE  (A,B)  (20)  FIXED; 

DECLARE  ($11,  $12,  $13,  $14)  FIXED; 
$12  =  LBOUND(A) ; 

$13  =  1; 

$14  =  HBOUND(A) ; 

DO  $11  =  $12  BY  $13  TO  $14; 

A($I1)  =  B ($1 1) ; 

END; 


DECLARE  (A,B)  (20)  FIXED; 

DECLARE  ($11,  $12,  $13,  $14)  FIXED; 
$12  =  LBOUND(A)  ; 

$13  =  1; 

$14  =  HBOUND(A) ; 

$11  =  $12; 

$15  =  IF  $11  >  $12  THEN  GO  TO  $16; 
A($I1)  =  B($I1) ; 

$11  =  $11  +  1; 

GO  TO  $15; 

$16: 
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6 .  Transformation  on  the  Computation  Tree 

For  a  given  program  (Figure  6.1)  the  recognizer  can  automatically  com¬ 
pute  the  phrase-structure  tree  (Figure  6.2),  which  can  then  be  reduced  to  a 
computation  tree  by  renaming  the  nodes  with  language-directed  actions  and 
deleting  those  that  call  for  no  operation.*  The  computation  tree  (Figure  6.3) 
then  constitutes  a  data  structure  with  an  interpretation  that  is  invariant 
under  certain  transformations.  Both  reducing  the  number  of  primitives  (sim¬ 
plification)  and  improving  the  code  efficiency  (optimization)  are  useful 
goals.  In  the  example  the  concepts  of  pre-evaluating  constant  subexpressions 
and  linearizing  integer  multiplication  are  illustrated.  The  reader  should  be 
aware  that  there  are  many  other  useful  transformations. 

Figure  6.1 
A  Source  Text 

i=i; 

DO  FOREVER; 

IF  I  >  HBOUND(A, 1)  THEN  RETURN; 

A(I ,  J)  =  B (I ,  J)  +  (I  +  1)  *3/J ; 

1=1+1; 

END 


*  Frank  DeRemer  calls  the  tree  in  Figure  6.3  the  abstract  syntax  tree.  The 
transformation  from  phrase-structure  tree  to  abstract  syntax  tree  can  be 
formalized  to  the  point  of  allowing  the  compiler  writer  to  specify  it  in 
tabular  form,  thus  avoiding  the  rather  messy  task  of  manipulating  the  tree 
directly . 
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Figure  6.2 

Phrase- structure  Tree  for  Text  in  Figure  6.1 
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Figure  6.3 

Computation  Tree  from  Figure  6.2 
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The  loop  has  an  induction  variable  (I)  which  is  stepped  by  a  constant 
amount  (1).  This  fact,  discovered  by  examination  of  the  computation  tree, 
allows  multiplication  by  a  constant  (or  unchanging  variable)  to  be  turned 
into  addition.  The  generally  slower  execution  time  of  multiplication 
together  with  common  subscript  algorithms  which  imply  a  fixed-point  multi¬ 
plication  means  that  there  is  considerable  to  be  gained.  Figures  6.4 
through  6.13  depict  subsequent  stages  of  the  computation  tree  as  the  various 
phases  of  the  transformations  are  carried  out. 

Each  figure  should  be  compared  with  an  earlier  figure  (usually 
Figure  6.3)  to  get  a  before/after  view  of  the  transformation  being  illus¬ 
trated. 
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In  Figure  6.4,  the  array  A,  having  declared  elsewhere  to  have  an 
upper  bound  of  8,  yields  a  constant  for  the  function  HBOUND.  In 
Figure  6.5,  the  double  subscripts  are  turned  into  simple  single  subscripts 
with  polynomial  values.  The  multiplication  of  an  induction  variable  is 
linearized  by  creating  a  new  induction  variable  ($12)  which  is  stepped  by 
the  multiplier  (Figure  6.7).  Then  addition  of  constants  are  twice  pushed 
off  onto  the  new  induction  variable  (Figures  6.8  and  6.9).  Then  the  use 
of  the  variable  I  directly  after  it  has  been  set  to  a  constant  value  allows 
some  pre-evaluation  (Figure  6.10).  Finally,  the  remaining  multiplication 
by  a  constant  is  pushed  out  to  the  leaves  of  the  computation  tree 
(Figure  6.11)  so  that  it  too  can  be  linearized  (Figure  6.12).  The  result¬ 
ing  tree  is  displayed  in  Figure  6.13. 

Tree  transformations  consume  more  computational  resources  than  most 
other  phases  of  translation  both  because  the  tree  occupies  a  lot  of  memory 
and  following  the  links  takes  a  lot  of  time.  Thus  the  implementor  must  be 
careful  in  deciding  which  transformations  are  economically  justified. 

Tree  transformations  are  easier  to  carry  out  when  the  source  language  does 
not  include  a  GO  TO  construct  to  break  up  sequences  of  code,  thereby  making 
difficult  the  detection  of  induction  variables  and  the  like. 
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Figure  6.4 

Pre-evaluating  Constant  Subexpressions 
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Figure  6.5 


Replacing  Double  Subscripts  with  a  Single  Polynomial 
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Figure  6.6 


Combining  Common  Subexpressions 
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Figure  6.7 

Linearizing  an  Integer  Multiplication 
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Figure  6.8 

Removing  Linear  Terms  from  a  Loop 
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Figure  6.9 

Combining  Variables  with  a  Common  Value 
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Figure  6.10 

Pre-evaluating  Constant  Subexpressions 
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Pre-multiplying  by  a  Constant 
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Figure  6.12 

Linearizing  an  Integer  Multiplication 
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Figure  6.13 

Computation  Tree  After  Simplification  and  Optimization 
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7.  Transformations  on  Language -Specific  Sequential  Code 

The  computation  tree  yields  the  language- specific  sequential  code 
partly  by  resort  to  zero-address  code  (a  left-of-right  sweep  of  the  tree) 
and  partly  by  insertion  of  transfer  instructions  where  implied  by  the 

f 

tree  (IF,  THEN,  ELSE,  loop,  procedure  calls,  etc.)-  The  transfers  can 
either  be  conventional  branches  or  more  restricted  transfers  correspond¬ 
ing  to  CASE,  CALL,  RETURN,  REPEAT,  etc.  Such  a  code  for  the  tree  in 
Figure  6.13  is  given  in  Table  7.1. 

Most  of  the  transformations  that  can  be  carried  out  on  the  computa¬ 
tion  tree  can  also  be  carried  out  on  the  language-specific  sequential 
code  [Allen  71,  Cocke  §  Schwartz  70].  In  addition,  the  branching  struc¬ 
ture  itself  is  open  to  some  optimizations  (e.g.  if  the  destination  of  a 
branch  instruction  is  an  unconditional  branch,  the  first  branch  can  be 
reformulated  to  go  directly  to  its  ultimate  destination). 
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Figure  7.1 

Sequential  Form  of  Figure  6.13 

LIT  I;  LIT  1;  STORE;  LIT  $11;  LIT  J;  LOAD;  STORE;  LIT  $13; 
LIT  6;  STORE;  LIT  $14;  CALL  ... 


$14: 

LIT  I;  LOAD; 

LIT  8;  GT; 

LIT  $15; 

BRANCH  FALSE 

;  RETURN ; 

$15  : 

LIT  A;  LIT  $11 

;  LOAD;  ADD; 

LIT  B; 

LIT  $11;  LOAD;  ADD; 

LOAD; 

LIT  $13;  LOAD 

;  LIT  J;  LOAD;  DIV; 

ADD;  STORE; 

LIT  I; 

LIT  I; 

LOAD;  LIT  1; 

ADD;  STORE; 

LIT  $11 

;  LIT  $11; 

LOAD; 

LIT  8; 

ADD;  STORE; 

LIT  $13;  LIT 

$13;  LOAD;  LIT  3; 

ADD;  STORE 

LIT  $14;  REPEAT; 
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8.  Transformations  on  Machine  Code 

The  translator  emits  machine  code  by  passing  over  the  language- 
specific  code  with  a  simulated  language-specific  machine  which,  instead 
of  evaluating,  emits  code  (Table  8.1).  Figure  8.1  displays  several 
stages  of  the  stack  during  the  execution  of  such  an  algorithm 
[McKeeman  et  al  70] . 

Table  8.1 


Source  Text  and  Language-specific  Code 


X=X+1 ; 

IF  X 

<  3  THEN  GO  TO  L; 

LIT  X; 

LIT  X; 

LOAD; 

LIT  1;  ADD; 

STORE ; 

LIT  X; 

LOAD; 

LIT  3; 

LT;  LIT  $L1; 

BRANCH_FALSE ; 

LIT  L; 

BRANCH; 

$L1 : 

Most  computers  have  peculiarities  that  are  utilized  by  assembly 
language  programmers  but  are  not  directly  available  to  the  compiler, 
partly  because  the  opportunities  to  make  use  of  them  do  not  become 
apparent  until  after  the  machine  code  itself  has  been  emitted,  and 
partly  because  they  are  special  to  the  target  machine  in  question 
[McKeeman  65].  Table  8.2  shows  a  typical  situation  of  this  kind.  At 
stage  1  we  have  a  good  machine  code  for  the  two  statements.  Because 
addition  is  commutative,  the  addresses  of  a  pair,  LOAD  ADD,  can  be 
interchanged  (stage  2)  which  permits  the  slow  LOAD  =1  to  be  replaced 
with  a  fast  load  immediate  LI  1  and  also  saves  the  cell  containing  the 
constant  1  (stage  3) .  In  any  pair,  STORE  X  LOAD  X,  the  LOAD  can  be 
dropped  if  it  is  not  the  destination  of  a  branch  (stage  4) .  Any  pair 
of  branches,  where  the  first  is  a  conditional  skip  and  the  second  is 
unconditional  can  be  reduced  to  a  single  conditional  branch  (stage  5) . 
Finally,  on  a  machine  with  an  add-one-to-memory  instruction,  the  sequence 
LI  1,  ADD  X,  STORE  X  can  be  combined  into  one  instruction  (stage  6). 
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Figure  8.1 

An  Emitter  Turning  Zero-address  Code  into  Single-address  Code 
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Table  8.2 


Transformations  on  Machine  Code 

Stage  1 

LOAD  X 

ADD  =1 

STORE  X 

LOAD  X 

LT  =3 

BRANCH  FALSE  $L1 

BRANCH  L 
$L1 : 

Stage  2 

LOAD  =1 

ADD  X 

STORE  X 

LOAD  X 

LT  =3 

BRANCH  FALSE  $L1 

BRANCH  L 
$L1 : 

Stage  3 

LI  1 

ADD  X 

STORE  X 

LOAD  X 

LT  =3 

BRANCH  FALSE  $L1 

BRANCH  L 
$L1 : 

Stage  4 

LI  1 

ADD  X 

STORE  X 

LT  =3 

BRANCH  FALSE  $L1 

BRANCH  L 
$L1 : 

Stage  5 

LI  1 

ADD  X 

STORE  X 

LT  =3 

BRANCH  TRUE  L 

Stage  6 

INDEX  X 

LT  =3 

BRANCH  TRUE  L 
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Innumerable  ingenuities  can  be  applied.  Since  the  savings  can  be 
dramatic  (as  in  the  example) ,  the  technique  is  useful  and  popular.  Noth¬ 
ing  makes  the  hero-author  of  a  compiler  happier  than  producing  really  sub¬ 
tle  correct  code,  beating  the  assembly  programmer  at  his  own  game.  One 
must,  however,  guard  against  introducing  errors  into  the  code  as  a  result 
of  not  carefully  considering  the  conditions  under  which  the  transforma¬ 
tions  leave  the  program  invariant. 
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9.  Fragmentation  Planes  in  the  Translator 

There  are  many  reasons  to  want  to  break  a  compiler  into  pieces.  The 

ability  to  run  the  translator  in  a  small  memory  is  one  which  the  computer 
salesman  and  computer  purchasers  feel  important.  The  problem  of  managing 

large  programming  projects  have  demanded  a  task  organization  which  results 
in  many  small  well-defined  subtasks.  Further,  there  seems  to  be  a  definite 
limit  on  how  complex  a  task  can  be  attempted  without  incurring  exponentially 
growing  delays  and  costs.  There  even  seems  to  be  a  critical  size  beyond 
which  repairing  an  error  introduces  on  the  average  of  more  than  one  error 
[Lehman  71].  And,  finally,  no  matter  how  well  a  system  seems  to  perform,  it 
is  good  engineering  practice  to  know  how  well  and  under  what  range  of  con¬ 
ditions  the  system  will  perform. 

Such  knowledge  comes  from  understanding,  understanding  comes  from  not 
having  to  consider  something  complex  all  in  one  mental  step. 

There  are  some  principles  that  guide  the  choice  of  natural  boundaries 
between  program  modules.  A  boundary  is  good  if  there  are  few  references 
across  it  into  other  modules  and  those  references  are  relatively  infrequently 
exercised.  A  boundary  is  good  if  the  information  flow  through  it  can  be  sim¬ 
ply  described.  A  module  is  good  if  its  function  can  be  simply  described.  A 
data  flow  is  good  if  it  can  be  totally  produced  before  any  of  it  is  consumed 
(meaning  no  feedback  is  needed  across  the  boundary) .  A  set  of  modules  is 
good  if  execution  activity  can  be  isolated  in  small  subsets  (working  sets) 
over  substantial  spans  of  time.  And  such  a  set  is  well-designed  if  particular 
dependencies  are  isolated  in  small  subsets  (e.g.  target  language  does  not 
appear  until  the  very  last  stages  in  Figure  4.1).  It  is  also  of  value  if  one 
module  can  be  changed  without  involving  the  processing  of  many  other  modules. 
We  can  suppress  detail  by  considering  a  subset  of  the  modules  as  a  single 
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module  where  the  internal  data  transactions  and  control  transfers  are 
ignored.  The  boundary  around  such  a  supermodule  is  good  if  the  resulting 
module  obeys  the  rules  above. 

The  technique  of  engineering  programs  are  being  developed  [Dijkstra 
69].  One  of  them  is  modular  programming  which,  when  applied  to  translators, 
depends  upon  the  organization  of  the  translator  (e.g.  Table  4.1)  and  upon 
the  application  of  the  principles  above.  The  time  should  soon  come  when 
translators  are  well-engineered  as  a  rule,  not  as  an  exception. 
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